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We present an elaboration of inductive definitions down to a universe of 
datatypes. The universe of datatypes is an internal presentation of strictly 
positive families within type theory. By elaborating an inductive definition 
- a syntactic artifact - to its code - its semantics - we obtain an internalized 
account of inductives inside the type theory itself: we claim that reasoning 
about inductive definitions could be carried in the type theory, not in the 
meta-theory as it is usually the case. Besides, we give a formal specification 
of that elaboration process. It is therefore amenable to formal reasoning 
too. We prove the soundness of our translation and hint at its correctness 
with respect to Coq's Inductive definitions. The practical benefits of this 
approach are numerous. For the type theorist, this is a small step toward 
bootstrapping, i.e. implementing the inductive fragment in the type theory 
itself. For the programmer, this means better support for generic program- 
ming: we shall present a lightweight deriving mechanism, entirely definable 
by the programmer and therefore not requiring any extension to the type 
theory. 

In a dependent type theory, inductive types come in various shapes and forms. Un- 
surprisingly, we can define data-types a la ML, following the sum- of -product recipe: we 
offer a choice of constructors and, for each constructor, comes a product of arguments. 
An example of such definition is the vintage and classic List datatype: 

data List [A : Set] : Set where 
\-\stA 3 nil 

| cons (a: A) (as: List a) 

For the working semanticist, this brings fond memory of a golden era: this syntax has 
a trivial categorical interpretation in term of signature functor, here LaX = 1 + A x X. 
Without a second thought, we can brush away the syntax, mapping the syntactic rep- 
resentations of sum and product to their categorical counterpart. Handling parameters 
comes at a minor complexity cost: we merely parameterize the functor itself, for instance 
with A here. 

However, these data-type definition are child's play in a dependently-typed setting: 
they do not let us use any type dependency in their definition, nor do they let us 
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define in ductive depen dent types. To obtain grown-ups' datatypes, we move to inductive 
families Dvbierl . 119941 ]: we first introduce the notion of index that, unlike parameters, 
we can constrain to a particular value. The archetypal example of an inductive family 
is the Vec datatype, which can understood as a list indexed by its length: 

data Vec [,4 : Set] (n: Nat): Set where 
Vec^ (n = 0) 3 nil 

Vec^ (n = sue n') 3 cons (n' : Nat)(a : A)(vs : Vec^ n') 

In our syntax, we are purposely explicit about constraints on indices. Indeed, these 
constraints eventually turn into a statement using whatever propositional equality the 
underlying type theory has to offer. 

Alternatively, our model of inductive families Morris and Altenkirch . 20091 ] suggests 
that vectors could be defined by first matching over the index n: if n is 0, then the only 
possible constructor is nil, otherwise, if n is sucm for some m, it must be a cons which 
tail is of length m. We reflect this definition style - computing over indices - by the 
following syntax: 

data Vec [A : Set](ti : Nat) : Set where 
Vec a n <= Nat-case n 
Vecyi 3 nil 

Vec,i (sue m) 3 cons (a:A)(vs:\/ecA m) 



Note that we are here using the Epigram by (<=) gadget IMcBride and McKinnal. 12004 ] 
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to pe rform the case analysis on n. A pattern-matching notation |Coquandl . 
20101 ] could be used as well. When the patterns are unsurprising, we shall abuse notation 
and write a standard pattern match. 

This definition style lets us maximally use the information provided by the indices 
to structure datatypes. In the constraint-based definition, we have to store an index n' 
against which we constrain n. In the computation-based definition, we s imply match 
again st the index. Such difference of presentation has been studied by iBradv et al. 



20031 ] in the context of various optimizations on in ductive types. In our work on orna- 



ments [McBridd . [2012J, iDagand and McBridd . 120121 ] , this definition style is instrumental 
in structuring our universes of functional ornament and enables us to lift functions across 
ornamented types. 

Now, we ought to make sure that our language of data-type is correct, let alone 
semantically meaningful. Indeed, if we were to accept the following definition 

data Bad [A : Set] : Set where 
Bad A 3 ex (f:BadA^A) 

we would make many formal develop ments a l ot eas ier to p rove! To ban these bogus defi- 
nitions, theorem provers such as Agda [Norelll . 120071 ] or Coq The Coq Development Team ] 
rely on a positivity checker to ensure that all recursive arguments are in a strictly posi- 
tive position. The positivity checker is therefore part of the trusted computing base of 
the theorem prover. Besides, by working on the syntactic representation of datatypes, 
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it is a non negligible piece of software that is a common source of frustration: it either 
stubbornly prevents perfectly valid definitions - as it sometimes is the case in Coq - or 
happily accepts obnoxious definitions - as Agda users discover every so often. 

For the working semanticist, this is an awakening and a rude one: while reasoning 
about ML datatypes used to be at a functor away, she now has to cope with equal- 
ity constraints and computations on indices. Most infuriatingly, we have some elegant 
models for indu ctive families but we see m stuck with some clumsy syntactic presen- 
tation: quoting lHarper and Stond 20001 ]. "the treatment of datatypes is technically 
compl ex, but conceptually straightforward". Following S tone and Harper, most au- 
thors [Asperti et all . l20ll ILuoL Il994l . iMcBride et al.l . l2004l ] have no choice but to throw 
in the towel and proceed over a "... "-filled skeleton of inductive definition. While this 
does not make these works any less correct, it makes them hard for the author to get 
right and for the reader to understand. 

We attribute these difficulties to the formal gap between the syntax of inductive defi- 
nitions and their semantics. While inductive families have an interpretation in term of 
strictly positive functors and their initial algebra, we are unable to leverage this knowl- 
edge. Being stuck with a syntactic artifact, the ghost of the de Bruijn criterion haunts 
our type theories: inductive definitions elude the type checker and must be enforced by 
a not-so-small positivity checker. Besides, since the syntax of inductive definitions is 
hardly amenable to formal reasoning, we are left wondering if its intended semantics is 
indeed always respected. How many inductive skeletons might be hidden in the dark 
closet of your favorite theorem prover? 

An alternative to a purel y syntactic approa ch is to reflect inductive types inside the 
type theory itself. Following Benke et al. 20031 ] . we extend a Martin-Lof type theory with 



a un iverse of inductive families, all that for a minor complexity cost [Chapman et al. 
2010 ] . From within the type theory, we are then able to create and manipulate datatypes 



but also compute over them. However, from a user perspective, these codes are a no-go: 
manually coding datatypes, for instance, is too cumbersome. Rather than writing low- 
level codes, we would like to write a honest-to-goodness inductive definition and get the 
computer to automatically elaborate it to a code in the universe. 

In this paper, we elaborate upon (pun intended) the syntax of datatypes introduced 
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Daeand and McBridd |2012j ]. In our previous work, we presented a conservative ex- 



tension of an Inductive-like syntax, the twist being in our support of computation over 
indices. While this syntax had been informally motivated, this paper gives a formal 
specification of its elaboration down to our universe of datatypes. Our contributions are 
the following: 



In Section [21 we give a crash course in elaboration for depen dent types. We will 
present a bidirectional type checker (Pierce and Turner! . 119981 ] for our type theory. 
We then extend it to make programming a less cryptic experience. To that purpose, 
we shall use types as presentations of more high-level concepts, such as the notions 
of finite set or of datatype constructor. While this Section does not contain any new 
result per se, we aim at introducing the reader to a coherent collection of techniques 
that, put together, form a general framework for type-directed elaboration ; 
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• In Section[3l we specify the elaboration of inductive types down to a simple universe 
of inductive types. While the system we present in this Section is restricted to 
strictly positive types, we take advantage of its simplicity to develop our intuition. 
The same ideas are at play in the case of inductive families ; 

• In Section HI we specify the elaboration of inductive families down to our universe 
of inductive families. This system subsumes the one introduced in Section [3] but 
we should reuse much of the concepts developed in that Section. The novelty of 
our syntax is to support computation on indices, as made possible by our model 
of inductive families and its universe presentation ; 

• In Section we draw the consequences of our design choice. For the proof- 
as sistant implementer, w e show how meta-theoretical results on inductives, such 
as iMcBride et al.l 20041 ] , can be internalized and formally presented in the type 
theory. For the programmer, we show how a generic deriving mechanism a la 
Haskell can be implemented from within the type theory. 

Scope of this work: This paper aims at specifying an elaboration procedure from an 
inductive definition down to its representation in a universe of inductive types. At 
the risk of disappointing implementers, we are not describing an implementation. In 
particular, we shall present the elaboration in a relational style, hence conveniently 
glancing over the operational details. Our goal is to ease the formal study of inductive 
definitions, hence the choice of this more abstract style. Nonetheless, this paper is 
not entirely disc onnected from implementation. First, it grew out of our work on the 



Epigram system [Brady et al.l ] . in which Peter Morris implemented a tactic elaborating 
an earlier form of inductive definition down to our universe of code. Second, a tutorial 
implementation of an elaborator for inductive types is currently underway. 



1 The Type Theory 



For t his paper to be self-con tained, we shall recall a few definitions from our previous 



work Chapman et all 120101 ] . We shall not dwell on the me ta-theoretical properties of 
this system: the interested reader sho uld consult iLud [19941 ] for a study of Martin-L6f 
type theory and lChapman et al.l 2010l ] for its extension with a universe of datatypes. 

We present our core type theory in Figure [TJ It is a standard Martin-L6f type theory, 
with S-types and II-types. We shall write Set/% for the hierarchy of types, implicitly 
assuming cumulativity of universes. In order to be equality-agnostic, we simply specify 
our expectations through a judgmental presentation. Our presentation is hopefully not 
controversial and should adapt easily to regional variations, such as Coq, Agda or an 
observational type theory [Altenkirch et all 120071 ] . 

A first addition to this core calculus is a universe of enumerations (Fig. [2|) . The purpose 
of this universe is to let us define finite collections of labels. Labels are introduced 
through the Uld type and are then used to define finite sets through the EnumU universe. 
To index a specific element in such a set, we write an EnumT code. To eliminate finite 
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I- VALID 
r h VALID rhg: SETfc 

r; x : S h VALID 

Th S:SET k 



r h VALID 



r;i4i:5h valid 
(a) Context validity 



rhS:SET r;a;:S'h<:T 

rh^:5 

r F (\x:S.t) s ee i[s/a;]:T[s/:z;] 

r h s:S r;a;:S h T:Set 

r h t:r[s/a;] 

r F 7T ((s,t) a .T) = s:S 

Ths:5 r;a;:5l-r:SET 
T h t:T[s/x] 

(b) Judgmental equality 



rhs:5 rhgEEr:SET fc 
r h s:T 

r h VALID r h VALID 



r;i:g;Ah valid 
T;x:S; A h a; : S 

r h VALID 

T h SET fc : SET fe+ i r hi: SET* Th*:l 

Thg'iSETfc r;a;:ghr:SET fc 
Th (x:S) xT:SET fc 

rhs:S h r:SET fc rhf:T[s/i] 

rh(s,t) x . T :(x:S)xT 



rhp:(i:S)xr 
r h 7Tq p : 5 



rhp:(.i:g)xT 
T h 7rip:T[7r p/a;] 



rhS:SET fc r ; a;:g h T:SET fc 



:5)^T:Set a 



rhS*:SET fc 
T:x:S h t:T 



rh/:(i:5)^T 

rhs:g 

r h Az:5'.i:(a;:5)-^r T^fs:T[s/x] 

(c) Typing judgments 



Figure 1: Type theory 



sets, we form a small IT-type 7r : (E : Enumll)(P : EnumT E — > Set) — > Set that builds a 
lookup tuple mapping, for all label e in the enumeration, a value of type Pe. To perform 
the lookup, we define the eliminator: 

switch : (E : Enumll)(P : EnumT E ->• Set) -)• 7r P P -> (x : EnumT P) P x 

Example 1 (Coding {'a, '5, 'c}). We define this set by merely enumerating its labels, in 
effect building a list of tags: 

{'a, '6, 'c} = consE 'a (consE '6 (consE 'c nil E)) : EnumU 

Example 2 (Coding {'a h-> e a , '6 i-> e^, 'c i-> e c } : (x : EnumT {'a, '6, 'c}) — >■ P x). We de- 
fine this function by a straightforward application of the switch eliminator: 

{'a H> e a , '6 e&, 'c i-> e c } = switch (consE 'a (consE '6 (consE 'c nilE))) P (e a , (e^, (e c , *))) 

We recall the definition of our universe of inductive types in Figure [3J This universe 
captures strictly positive types, a generalization of ML datatypes to dependent types. 
For pedagogical reason, we choose this simple universe as a first step toward a full-blown 
universe of inductive families. The idea at work behind this presentation is the following: 
to define new datatypes, we give their code by describing their signature functor in 
Desc. The interpretation function [_] turns such a description into the corresponding 
endofunctor over Set. Its definition is obvious from the codes: a '£ is interpreted into 
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r h VALID 



T h Uld:SET 



r h VALID 

r h 's:Uld 



a valid identifier 



(a) Tags 



T h VALID 

T h EnumU : Set 

T h VALID 

T h nilE:EnumU 
Tht:Uld rhg:EnumU 



T h £: EnumU 
T h EnumT I : Set 

r h VALID 

T h 0: EnumT (consE t E) 
T h n:EnumT£ 



r F 1+ n : EnumT (consE t E) 
(c) Index 

Figure 2: Universe of enumerations 



T h consE £ I : EnumU 

(b) Enumeration 



T h VALID 
T h Desc:SETi 

T h VALID T h VALID 



rh 'var: Desc Th'liDesc 

rhi: Desc V \- B: Desc 
rhi'x£: Desc 

r h : Set T:S^ Desc 

rh'nSI 1 : Desc 

r h £ : Set T:S^ Desc 

T h '£ S T : Desc 

rhI:EnumU rh T:EnjmT£ 



Desc 



rh'ffET: Desc 
(a) Codes 



[(D:Desc)] (X:Set) : Set 
['varj X ^ X 
['1] X ^ 1 
\A>xB\ X i y {A} Xx IB] X 
fUS Tj X ^ (s:S)^ lTsj X 
{'US Tj X h+ (s:S)x [TsJ X 
I'aE Tj X m- (e: EnumT E) x [T e] X 



rhJ: Desc 
T h /i I? : Set 



r h \nxs:fiD 



(b) Fix-point 



induction : (D : Desc)(P : /iD -> Set) : [D] Qui))) -)• All I> (/iD) P d -)■ P(ind)) -)• (z : /^D) -> la; 

(c) Elimination principle 



Figure 3: Universe of inductive types 



a S-type, and so on. The notable exception is 'var, which describes the identity functor. 
Remark that the resulting functor are strictly positive, by construction. Hence, we can 
construct their least fix-point using \x and safely provide a generic elimination principle, 
induction. The All function comp utes the inductive hyp othesis. The interested reader 
will find their precise definition in Chapman et al. 201(j | but the basic intuition we have 



given here is enough to understand this paper. 

Example 3 (Describing natural numbers). Natural numbers can be presented as the 
least fix-point of the functor FX = 1 + X. This is described by: 

NatD : Desc 

r 'o l r 'o l Nat : Set 

NatD 4 V< , ' }\ , ' } Nat H- u NatD 

[ sue J [ sue H> var J 

Note that we are using a small V here: a datatype definition always st arts with a finite 



choice of constructors. This corresponds to the tagged descriptions of IChapman et al. 



2O10l ]: using this structure, we can implement some generic constructions - such as the 



Zipper or the free monad - and generic theorems - such as in Section 15.1 
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r h 7: Set 
T h IDesc/: Set 

r h ill 

r h 'var i: IDesc/ 

r h VALID 

r h '1: IDesc/ 

rh .4: IDesc/ rhff: IDesc/ 
T h 4'x 5:IDesc/ 

Th^iSET rhTig^lDesc/ 
rh'n5 T:\DescI 

T h 5 1 : Set T h Tig^lDesc/ 
rh'ES T: IDesc/ 

rh^:EnumU r h T : EnumT E H> IDesc I 
T\-'aE T: IDesc I 

(a) Codes 



[(D: IDesc/)] (X:/^Set) : Set 
['var j] 

I'll X * 1 

I^'xB] X h- [A]Ix[B]I 

['115 r]l ^ [j:S)-»[T«] X 

['E5 T] X ^ (a: 5) x [Ts] X 

['cr E T\ X ^ (e : EnumT E) x\T e\X 

r h/ D :/-> IDesc/ 
r h /x 1 : / -> Set 

r h \n xs : fj, 1 fo i 
(b) Fix-point 



iinduction: (P :/ -> IDesc /)(P : ((« : /) x /J R i) ->• Set) ->■ 

((i:/)(a»:[iiil £)) -mAII (//P) zs P ->P («, in as)) -> 
(i:I)(x:fjlRi)^p{i,x) 

(c) Elimination principle 
Figure 4: Universe of inductive families 



Example 4 (Describing binary trees). Categorically, binary trees are modeled by the 
least fix-point of the functor TaX = 1 + A x X 2 . In our universe, we obtain trees by the 
following definitions: 

TreeD (A : Set) : Desc 

-pp. a , f 'leaf, 1 f 'leaf H- '1, 

TreeD ^4 !->• V 



node J (_ 'node i-4 'var 'x 'S ^4 A_. 'var 
Tree (^4: Set) : Set 
Tree A h-> /i (TreeD A) 

Finally, we recall the universe of indexed descriptions (Fig. which captures induc- 
tive families. This universe subsumes the previous one by not only allowing parameters 
but also indices: thanks to this universe, we can describe datatypes such as vector. Just 
as before, we give a universe of codes, IDesc, that are then interpreted to build the least 
fix-point. Note that the argument of fx 1 is a function from indices to codes: this partic- 
ularity lets us define datatypes by computation over the index. We illustrate this point 
through two possible implementations of the vector datatype. 

Example 5 (Vector, a la Coq). The standard presentation of inductive families is by 
using equality constraints to force the indexing strategy. In effect, this corresponds to 
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the following definition of vectors: 



VecD (A : Set) (n : Nat) : IDesc Nat 

VecD A n H> V j'"' 1 ' 1 

[cons J 

J 'nil H. 'E(n = 0) A_. '1, 1 
\'cons (->■ '£ Nat Am. 'S (n = (sucm)) A_. 'SiA.. 'varmj 

Vec (A: Set) (n:Nat) : Set 

Vec A n ^ (VecD A) n 

Example 6 (Vector, alternatively). Interestingly, in the previous definition, we are 
defining Vec/? as a function from (n: Nat) to IDesc Nat but we are not making use of our 
ability to inspect n: we merely constrain it to be what we wish it was. We can make 
full use of that function space by first checking whether n is or sue m and only then 
give a code for the corresponding constructor, respectively nil and cons: 



VecD (A: Set) (n: Nat) : IDescNat 

VecD A 1-4 '1 

VecD A (sucm) H> 'XMA_. 'varm 



Vec (A: Set) (n: Nat) : Set 

Vec A n i-> /j (VecD A) n 



2 First Steps in Elaboration 

In this Section, we shall make our first steps in elaboration. First, we present a 
bidirectional type system for the calculus introduced in the previous section. Using 
the flow of information from type synthesis to type checking, we are then able to 
decl utter our term language. Se condly, we adapt the notion of programming prob- 



lem [McBride and McKinnal . 120041 ] to our system and we shall see how, with little effort, 
we can move away from an austere calculus and closer to a proper programming lan- 
guage. 



2.1 Bidirectional type checking 

The idea of bidirectional type checking Pierce and Turner . 1998| is to capture, in the 
specification of the type checker, the local flow of typing information. On the one hand, 
we will synthesize types from variables and functions while, on the other hand, we will 
check terms against these synthesized types. By checking terms against their types, 
we can use types to structure the term language: for example, we remove the need for 
writing the domain ty pe in an abstraction, or w e can use a tuple notation for telescopes 
of S-types. Following Harper and Stond . 120001 ] . we distinguish two categories of terms. 
The core type theory defines the internal language. The bidirectional approach lets 
us then extend this core language into a more convenient external language. We shall 
hasten to add that using a bidirectional approach in a dependently-type d framework is 



not a novel idea: for instance, it is the basis of Matita's refinemen t system Asperti et al. 



20121 ] . Also, we gave a similar presentation in some earlier work Chapman et all 120101 ] . 
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rhSET^r^r' FhT'3t c ^ k t' 

rh(t:T)S('eT' 
T; x:ff; A h valid 
T; x : S; A \- x ^ x £ S 

rh/^/'e(x:5)^T 

rh/s^/'s'e T[s'/x\ 

Thp^p' €(x:S)x T 

1 h 7ToP TTqP € D 

rhp^ P '£(i:5)xr 

r h irip ^ 7Tip' € T[ttqp' jx\ 
(a) Type synthesis 



Ths^s'eS rhg = T:SET fc 

r h VALID 

T h SET fe+ i 3 SET fe ^ SETfc 

r h SET fc T;x:S'\- SET k 3T™T' 

F h SET fc 3 (x:S)^T C ™(x: S') -> T' 

r;i:5h T3t C ^t' 

Chk - 



F \- (x : S) T 3 Ax. t -*%"kx: S. t' 



Chk 



Chk , 



r h SET fc BS^S' r; g : S' h SET fc 3T ^T' 
F h SET fc 3 (x : S) x T ^ (x : S') x T' 

rh( I: S)xn(M)-(s',i'),T 

r h VALID T h VALID 



CM 



r h SET fc si ™i 

(b) Type checking 
Figure 5: Bidirectional type checker 



ri ^ — . Chk 
hi 9 * * 



Let us present type synthesis (Fig. [5a|) first. The judgment r h ^ i' G T states 
that the external term t elaborates to the internal term t' of type T in the context T. 
By convention, we shall keep inputs to the relation to the left of the ~ > symbol, while 
outputs will be on the right. We expect the following soundness property to hold: 

Inf 

Theorem 1 (Soundness of type synthesis). If F h f ~» i' £ T, i/ien T h r :T. 

While type synthesis initiates the flow of typing information, type checking (Fig. I5bl) 
lets us make use of this information to enrich the language of terms. The interpretation 

Chk 

of the judgment F h T 3 t t is that the external term t is checked against the type 
T in context T and elaborates to an internal term t' . Again, we expect the following 
soundness property to hold: 

Chk 

Theorem 2 (Soundness of type checking). IfF\-T3t**>t', then F\~t:T. 
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2.2 Putting types at work 

While the type checker we have specified so far only allows untyped abstractions, we 
extend it with some convenient features. 



Tuples: By design of the interpretation of our universes of enumeration and inductive 
types, we are often going to build inhabitants of E-telescope of the form (a : A) x (6 : 
B) x . . . x (z : Z) x 1. To reduce the syntactic burden of these nested pairs, we elaborate 
a LISP-inspired tuple notation: 



A3x C ^x' r h B[x'/a] 3 (xs) *g xs' 



T h 1 3 () °^ * 



T h (a: A) x B 3 (x xs 



Chk , , n 

{x',Xs') a .B 



Finite sets, introduction and elimination: In Section [TJ we have used an informal set- 
like notation for enumerations: we can make that notation formal through elaboration. 
To do so, we extend the type checker with the following rules: 



Th EnumU 3 {ts} ~* E 



T h EnumU 3 {} ^ nilE T h EnumU 3 {'a, ts} consE 'a E 



T h EnumU 3 {%, . . . , %} ™ E V h n E P 3 (eg . ■ ■ e k ) es 

Chk 

T h (e: EnumT E) ^ P e 3 {'Z H> e^, . . . 7 fc i-> e/J switch E P es 



Indexing finite sets: Also, rather than indexing into enumerations through the EnumT 
codes, we would like to be able to write the label and have it elaborate to the corre- 
sponding index. This is achieved by the following extension: 



r h E 3 't<~tn 



T h consE 'tEB't^O T h consE >u E B 't °™ 1+n 



Datatype constructors: Finally, while we do not yet have a proper syntax for declaring 
inductive types, we can already extend our term language with constructors. Upon 
elaborating an external term c ao • • • a k against the fix-point of a tagged description, 
we replace this elaboration problem with the one consisting of elaborating the tuple 
consisting of the constructor label and the arguments: 

r h n (V E T) 3 in Qc a . . . a k ) jjg t T h (J (V E T) i 3 in Qc a . . . a k ) ^ t 
T h /i ('cr E T) B c ao . . . a*, -2+ t r h /i' ('cj E T) i 3 c ao ... a& -£> t 
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r h valid rh Mabel T\-t:T 
rhf: label r h Z i: label 

r h Z:label T \- T: Set Tht:T r h Z:label T\-c:{l:T) 

rh(Z:T):SET r F return t:(l:T) T F call(Z : T)c:T 

(a) Programming label 

r h let / (x:X):Twhere^A 

r h Set 3 (x:X) -> T °™ (x:X') ->• T' 
r,(x:X') h (f x:T') 9 
T h let f (x:X):T where t-£>T[f ^ Ax : X'. call(f f : T')t' : (x :X'j ~T] 

(b) Program declaration 

T h (l:T) 3t£*t' 

l>pt rr^'e((^W^{i:T) 

r h (Z : T) 9 pi h-> e ^ return e' r h (I : T) 9 pt e{pl} £ e' (Xxl-.Xi. s 4 ) 

(c) Program definition 

Figure 6: Programming labels 



2.3 Elaborating Programs 

In the previous Section, we have define type-specific languages, relying on the types to 
guide the elaboration process. In this Section, we go a step further and purposely define 
finely indexed types for the purpose of elaboration. This idea of using types as a presen- 
tation of our high-level intentions rather th an a representation of low-level restrictions 



originated in llvlcBride and McKinnal 20041 ] . To illustrate our point, we redevelop the 



elaboration of programs presented in that paper and adapt it to our framework. We shall 
see how these presentation types guide the elaboration of programs and let us regain a 
pattern-matching notation without hard-wiring pattern-matching itself. 

To guide elaboration of programs, we define programming label types (Fig. [6]). In 
essence, a programming label (/ : T) is a phantom type around the type T. However, the 
label I is crucial in that it represents the arguments of the function we are implementing. 
A motivating example of label types is the definition of addition by explicitly using the 
elimination principle of natural numbers: 

(m: Nat) + (n:Nat) : ('+ m n : Nat) 
to + n i— > Nat-ind (Am'. ('+ to' n : Nat)) m 

{?:('+ On: Nat)} 

{? : (to : Nat) -)• ('+ m n : Nat) -)• ('+ (sue m) n : Nat)} 
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Thanks to the label types, we can relate every case of the elimination principle with the 
state of our programming problem. 

Using these label types, we can extend our external language to ease programming. 
First, we introduce a programming problem by the let command (Fig. I6bj) . The elabo- 
ration judgment is subject to the following soundness property: 



Theorem 3 (Soundness of program elaboration). If V \- let / (x:X) :Twherei-^A, 
then A h VALID. 

To elaborate the definition of the program, we restrict our attention to two constructs: 
returning a value using the Return (i— >) gadget and appealing to an elimination principle 
using the By ( ) ga dget. We shall ignore yiews and other syntactic conveniences 
originally introduced bv lMcBride and McKinnal 20041 ] . The elaboration rules are given 
in Figure [6cl The idea is that they are two rules to realize a programming label: either we 
return a term, or we decompose the problem further using an eliminator. We have coded 
the programming grammar within this specification. Remark the presence of patterns 
pt on the left hand side to mimic a pattern-matching notation. Intuitively, the relation 
l>pt makes sure that the pattern entered by user corresponds to the label computed by 
the type-checker. The relation The e ~^™ e' € T abstracts away the task o f generating a 



term e' in the internal language from an elimination form e, as described in lGoguen et al 



200d |. McBride 2002 ]. We will not recall this construction and simply assume that the 



generated term is well-typed with respect to T, i.e. T h e':T. 



3 Elaborating Datatypes 

In this Section, we specify the elaboration of inductive types down to our Desc uni- 
verse. While this universe only captures strictly positive types, it is a good exercise to 
understand the general idea governing the elaboration of inductive definitions. Besides, 
because the syntax is essentially the same, our presentation should be easy to understand 
for readers familiar with Coq or Agda. 

We adopt the standard sum-of-product high-level notation: 

data D [p:P\ :Set where 
D f 3 c (a :T ) 



I C/fc i a k '■ Tk) 

Where the arguments p are parameters. A Tj can be recursive, i.e. refers to D p. Note 
that it is crucial that the parameters are the same in the definition and the recursive 
calls. 

Our translation to code follows the structure of the definition. The first level structure 
consists of the choice of constructors and is translated to a 'cr code over the finite set of 
constructors. The second level structure consists of the S-telescope of arguments: these 
are translated to right-nested 'S codes. When parsing arguments, we must make sure 
that the recursive arguments are valid and translate them to the 'var code. 
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r h D datatel 



T h I datatel 
T h t: T 
r h It datatel 



r F (/):Seti 



h | datatel 



r h £:Enumll 
r h T:EnumT£'— s> Desc 
r F return ET:{1) 



r h call (0 t: Desc 



T\-t:(l) 



Figure 7: Description label 



3.1 Description labels 

To guide the elaboration of inductive definitions, we extend the type theory with de- 
scription labels (Fig. [7J). Their role is akin to programming labels: they structure the 
elaboration task and are used to ensure that recursive arguments are correctly elabo- 
rated. 

A description label (/) is a list starting with the name of the datatype being defined 
and followed by the parameters of that datatype. It can be thought as a phantom type 
around Desc. We can introduce such type using return that takes the (finite) set of 
constructors and their respective code: doing so, we ensure that we are only accepting 
tagged descriptions. With call (I) , we eliminate return by joining constructors and their 
codes in a V code, effectively interpreting the choice of constructors. 

3.2 Elaborating inductive types 

We shall present our translation in a top-down manner: from a complete definition, we 
show how the pieces fit together, giving some intuition for the subsequent translations. 
We then move on to disassemble and interpret each sub-component separately. As we 
progress, the reader should check that the intuition we gave for the whole is indeed valid. 
Every elaboration step is backed by a soundness property: proving these properties is 
inherently bottom-up. Only after having developed all our definition will we be able 
to prove the soundness of elaboration of inductive definitions. However, the proof is 
technically unsurprising: we shall briefly sketch it at the end of this Section. To further 
ease the understanding of our machinery, we shall illustrate every step by elaborating 
the following definition of binary trees: 



Elaboration of an inductive definition (Fig. I8a[): Elaborating an inductive definition 
extends the input context with the datatype definition. To obtain this definition, we 



data Tree [A : Set] : Set where 
Tree A 3 leaf 

| node(/:Tree^)(a:^)(r:Tree.4) 
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r h data D (p : P) : Set where choices S* A 



T h SETi 9 {p:P 
T,p:P' h (Dp) 9 choices code 



Set ^ (p:P') 

Cs 



Set 



> D > 

T h data D[p:P] : Set where choices — > r[.D ~kp. /j, (call (D code) : (p:P) — > Set] 

(a) Elaboration of definition 



r h (!) 9 choices -S code 



r h (!) 3 Cj i ^ codej 



rh EnumU 9 {U}^ E 



T h EnumT E -> Desc 9 i-> code;} ^ T 



Cs 



r h (/) 9 c | . . . |c„ -w return i? T 

(b) Elaboration of choices 



C 



r h (!) 9 c~>[i ^ code] 



r h uid 9 't^f 

rh (!) 9 args code 
T h (!) 9 i args-%' i— > code] 
(c) Elaboration of constructor 



r h (!) 9 args ~> code 



rhSET9T "r' r,x:T' h (!) 9 A-^code A To! r h (!) 9 A A code A 

r h (!) 9 (x : T) A 4 '£ T' Ax. code A r h (!) 9 (x :T)A •w 'var 'x code A 

r h Set gr*f I\t:T' h (!) 9 V-^code v 

rh (!) 9 A-A code A 
Th (!) 9 (/:(!:T)^V)A^('nr / A!.codev)'xcode A Th (!) 9e^'l 

(d) Elaboration of arguments 



D>~D Tpt>lp 
(e) Recursion matching 

Figure 8: Elaboration of inductive types 
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first elaborate the parameters and move onto elaborating the choice of constructors, 
introducing a description label in the process. 

Example 7 (Elaborating Tree). Applied to our example, we obtain: 

T h data Tree(A:SET):SETwhere[choices] ~^r[Tree AA/i(call (Tree ,4) [code] ) : ,4 — >• 
where 

choices = leaf | node (/: Tree A){a : A){r: Tree ^4) 

i a . f 'leaf, \ / 'leaf m- '1, \ 
code = return | ^ j j ' node ^ > var ?x > S ,4 A _. V ar 'x '1 J 

Elaboration of constructors (Fig. [5b) : To elaborate the choice of constructors, we 
elaborate each individual constructor, hence obtaining their respective label and code. 
We then return the finite collection of constructor names and their corresponding codes. 
This elaboration step is subject to the soundness property: 

{T h I datatel 
Cs ; then T h code: {I) 

r h (!) 9 choices ~~ > code 

Example 8 (Elaborating Tree). Applied to our example, we obtain: 

T, A : Set h (Tree A) 3 [choices] S[ co de] 
Where choices and code have been defined above. 



Elaboration of constructor (Fig. [8c]) : The role of this elaboration step is twofold. First, 
we extract the constructor name and elaborate it into a label. Second, we elaborate the 
arguments of that constructor, hence obtaining a Desc code. We return the pair of the 
label and the arguments' code, subject to the following soundness property: 

(Thl datatel (T\-t:Uld 
Lemma 2. If < n , then < _ , ^ 

\T h (/) 3 c^[t ^ code] \rhcode:Desc 

Example 9 (Elaborating Tree). Since our datatype definition has two constructors, 
there are two instances of constructor elaboration: 

T, A : Set h (Tree ,4) 3 leaf £['leaf ■->■ '1] 

T, A : Set h (Tree ,4) 3 node (I :Tree A){a: A){r :Tree A) £['node ^ 'var'x 'Y, A A_. 'var'x 
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Elaboration of arguments (Fig. 1 3d ft : The last and perhaps most interesting rule is the 
elaboration of arguments. Intuitively, the arguments form a telescope of S-types, hence 
our translation to 'E and 'x codes. The first two rules are non-deterministic: T could 
either be a proper type or a recursive call. In the first case, this maps to a standard 
'£ code, while in the second case, we must make sure that the recursive call is valid 
and, if so, we generate a 'var code. We also support exponentials in the definitions, 
mapping them to the 'II code. Once all arguments have been processed, we conclude by 
generating the '1 code. This translation is subject to the following soundness property: 

{r h I datatel 
A , then T h code : Desc. 

r h (/} 3 args ~» code 

Example 10 (Elaborating Tree). Elaborating the arguments of the leaf constructor is 
trivial: 



r, A : Set h (Tree ,4) 3 e<4'l 



As for the node constructor, we obtain its code through the following sequence of elab- 
orations: 

Tree A > Tree A 



r,^:SET,a:^ h (Tree ,4) 3 e-A'l 



T, ,4: Set, a: ,4 h (Tree ,4) 3 (r :Tree A) 4 'var 'x '1 

Tree y4 1> Ttgg A 

r,A:SET h (Tree ,4) 3 (a : A)(r : Tree A) 4 '£ A A_. 'var 'x '1 

r,^:SET h (TreeA) 3 (/:Treey4)(a:y4)(r:Tree^) 'var'x 'Sy4A_. 'var'x '1 

We can now prove the soundness of the whole translation. We formulate soundness 
as follow: 

> D 

Theorem 4 (Soundness of elaboration). IfYY- data D{p:P) : Set where choices ~^ A, 

then A h valid. 

Proof. First, we prove Lemma [3] by induction on the list of arguments. We then obtain 
Lemma (2) By applying this lemma to all constructors, we obtain Lemma [TJ From this 
Lemma, we finally obtain the soundness theorem. 

□ 

While our soundness theorem gives some hint as to the correctness of our specification, 
we could obtain a stronger result by proving an equivalence between Coq's Inductive 
definitions and the corresponding datatype declaration in our system. This equivalence 
amounts to proving the equivalence of the associated elimination forms, i.e. Fix in Coq 
and induction in our system. However, since we do not know of any formal description of 
elimination principles generated from an Inductive definition, we shall use the simpler 
presentation given in Gimene2 19951 ] . 
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The fact that our induction principle is provable in Coq is a known result [Chapman et all 



2010 ] . The other direction consists in proving that any Coq Fix definition can be im- 
plemented using our induction principle. To this end, we use Gimenez reduction of Fix 
definitions down to elimination rules. To prove this result, we first translate Gimenez 
constructor forms to our universe of code: 

[XN\ ^ '1 
[(x:M) -> C\ ^ 'EM Ax. |CJ 
[(x : M -> X N) -»• C\ t-> (TI M A_. Var) 'x \C\ 

We thus get a translation from his recursive types declaration to a code in our universe: 

Llnd(x: A)(C ...C n )\ ^'an{i^ [d\} 

Having done that, it is then a straigh tforward symbo l-pushing exercise to prove that 
Coq's elimination rules (Section 3.1.1, [Gimenezl . Il995l |) can be reduced to our generic 
elimination principle. The crux of the matter consists in showing that the minor premises 
- defined by E\ in that paper - maps to the induction hypothesis described by ((d : 
fD} (jiD)) -»• All D (jiD) P d^ P(ind)) in our system. 



4 Elaborating inductive families 

In this Section, we extend our treatment of inductive definitions to inductive families. 
To do so, we add support for indices and computation on these indices. The resulting 
system subsumes the one presented in the previous Section. Hence, we shall reuse many 
notations used previously: this should not affect reasoning or implementing this elabo- 
rator, since only that last system is necessary. We shall however develop our intuition 
of this more powerful presentation from the simpler translation of inductive types. 

The syntax we elaborate is strongly inspired by the syntax used by Agda and Coq. 
However, to support computation over indices, we support the Epigram-style by gadget 
( <= ). Our language of inductive definition is therefore more complex, following the 

skeleton: 

data D [p : P](i : i) : Set where 

D p (i = t ) B c fi(a 0) o-To t0 ) 



D pi 
D pk 

For anyone wanting to reason about Agda or Coq definitions, it is straightforward 
to simply discard the elaboration of computation over indices. Thus, with minor ad- 
justement, our formalization of elaboration gives a translation semantics to inductive 
definitions used in these main-stream theorem provers. 



elim in 
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r h VALID 



r h / idatatel 
r h p:P 



r h / idatatel 



r h / idatatel 
i:7 er 



r h D idatatel r h I [p] idatatel T \- I (i) idatatel r h I (i = t) idatatel 



r h £:EnumU 
r h l datatel r h T: EnumTff^ IDesc p] D 
Th(0:SETi r F return ET:{1) 



T\-t:{l) 
Thcall (l)t: IDesc p] D 



Figure 9: Description label (indexed) 



4.1 Description labels 

In Section T3. 11 we have introduced the notion of description labels. While it was enough 
to deal with parameterized definitions, we have to extend this notion to account for 
indexing. Besides, indexing can be either unconstrained - some index (i) - or it can be 
constrained to some particular value - such as (i = t). Besides, a label is not a phantom 
type around a description but around an I Desc I where I corresponds to the product of 
all index types the label is taking as arguments. 

These requirements lead us to the definition of description labels given in Figure [9l 
We define label's arguments through a telescope extended with indices and constraints. 
To compute the index type of the resulting description, we introduce the 1-}d function. 
Accordingly, we update the introduction and elimination rule of labels to account for 
the index type computed from the telescope. 

As for inductive types, we shall present the elaboration process in a top-down man- 
ner. This presentation shares some strong commonality with the simpler elaboration of 
inductive types: we elaborate choices of constructors (Fig. HUcj) . followed by individual 
constructors (Fig. HOdj) . and finally processing the telescope of arguments (Fig. Illaj) . 
However, the presence of indices introduces some new steps too. We support constraint 
of indices and computation over them through a new top-level rule (Fig. HObp . Besides, 
we must translate the constraints to actual equalities (Fig. Illcp and pass the correct 
indices when elaborating a recursive call (Fig. Illd|) . 



4.2 Elaborating inductive families 

To give a better intuition of a perhaps intricate system, we should illustrate every in- 
ference rule with two examples. Our first example is the definition of vectors relying on 
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r h data D[p : P](i : I) : Set where choices A 



CTifc 



Th Seti 3 (p : P) (i :/)->■ Set (p:P'){i: J') -> Set 
T;p:P';i:I' h (D [p] (ij) 9 choices code 



=F 



T h data Z)[p:P] (i : /) : Set where choices 



r[D i-» Ap:P'./i(Ai:P.call (D [p] (»)) code) : (p : P')(« : /' 
(a) Elaboration of definition 



r h (I) 3 patts F ^ S code 



Set] 



lDpti-^> k 
F\- (k) 3 csi Z*[{cij} !->■ {qj i->- osjj}] 



Z 2 pti+i ~* h+i 



rhe" e 'e((x t :I^(I fc })^(I !+1 



Patts 



T,x k :X k h (/ fc ) 3pk ^ code fe 



pi 9 cs 



r h (Z) 3 " -w return {c^j, 'elim} < cy i->- asjj, 'elim h-> e' (Ax^ :X k . call (Z) code^) 

PU 9CSi ' [ 

pij+i -<= e{pl} 

(b) Elaboration of patterns 



r.s r 



r h (i) 9 choices ^[P H> T] 



r h (I) 9 Cj ^ codei] 

r h (Z) 3 co| . . . \cn ^[{h} i-> ji, (->■ code; j] 

(c) Elaboration of choices 



r h (Z) 9 c«&[t ^ code] 



r h Uld 3 'c ^ c' r h (Z) 9 args 4 code 
r h (I) 9 c args ~-»[c i-> code] 
(d) Elaboration of constructor 

Figure 10: Elaboration of inductive families (1) 
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r h (!) 9 args ~» code 



r h Set 3 T C ^T' T,x:T' h (/) 9 A^code A 
T h (/) 9 (x:T) A ^ 'E T Ax. code A 



r h (/) 3 A ^> code A 



rh (/} 3 (x:T)A^(\aris) 'x code A 



r h Set T' 



r,x:T' h (Z> 9 V^codey 
r h (/} 9 A -A code A 



rh(I)9 (/:(x:T)^V)AA('nr / Ax.code v )'x code A 

(a) Elaboration of arguments 



Z i 



rh (0 3 e^q 



Z DT^Ij 



Z DT^iy 



DDD^D Z [p] D Tp-i>l T [p] l(i)DTi^l T (i) 



I (i) DT (i = t)~>l T (i = t) I (i = t) DT (i = t)~^ l T (i = t) 
(b) Pattern validation 



£ 9 
Z i 



T h VALID 



Eg 



Z [p] S 



Eg 

Z ~4 g 
i f\ Eq 



Eg 

Z i 



i:J G r 



Z(i = t)^'S(i = t')A-g 

(c) Elaboration of constraints 



l3T~>lS 



T h VALID 



Z [p] 3 T p^> is 



. „ LA . 

13 1 is 



I (i') 3 T i ^4 (is, i) 



Z 9 i ~> 



LA 



Z (i' = t) 3Ti^f(is,i) 

(d) Extraction of indices 
Figure 11: Elaboration of inductive families (2) 
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constraints to enforce the indexing discipline: 

data Vec [A : Set] (re: Nat): Set where 
Vec^ (n = 0) 3 nil 

Vec^ (re = sue n') 3 cons (re' : Nat)(a : A)(vs : Vec^ re') 

While our second example consists of the alternative definition of vector, where we 
compute over the index to determine which constructor to offer: 

data Vec [A : Set](ti : Nat) : Set where 
Vec a n <= Nat-case n 
VecA 3 nil 

Vec^ (sue m) 3 cons (a:A)(vs:\/ecA m) 

Elaboration of inductive families (Fig. llOafl : The elaboration of an inductive defini- 
tions sets up the environment to trigger the elaboration of the choices of constructors. 
To do so, we first elaborate the telescope of parameters and indices types. We can then 
translate the choices by elaborating against the label type corresponding to the given 
inductive type. 

Example 11 (Vector, constrained). The elaboration of constraint-based vectors starts 
as follow: 

Patts 

A : Set, re : Nat h Vec [A] (re) 3 [choices = ] ~> [code = ] 

h data Vec [A : Set] (n : Nat) : Set where [choices=] 

T[Vec ^ XA : Set. p (An : Nat. call (Vec [A] (n)) [code=]) : (A : SET)(n : Nat) -> Set] 

where 

i ■ a Vec^ (re = 0) 3 nil 

CllOlCGS 

~ Vec^ (re = sucrei) 3 cons (rre : Nat)(a : A)(vs : Vec^ m) 



code= = return 



'nil, 
'cons 

'nil M.'E(n = 0)A_.'l, 

'cons i-^ 'E Nat Am. '£ A A_. 'var (*, rre) 'x ! E (re = sue m) A_. T 

Example 12 (Vector, computed). The same skeleton is used in the alternative definition 
of vectors, but the choices of constructors - and therefore the resulting code - are 
different: 

V&ca n <= Nat-case n 
choices-,. = Vec^ 3 nil 

Vec a (sue m) 3 cons (a : A)(vs : Vec^ m) 

code_>. = return {'elim} 

Nat-case n (An. (Vec |yl](n))) 
'elim i-> (return {'nil} {'nil '1}) 

(Am. return {'cons} {'cons \-t '£ A A_. 'var (*, m) 'x '!}) 



21 



Elaboration of pattern choices (Fig. HObj) : This elaboration process is an extra step 
that was not necessary with inductive types. With inductive families, we can both 
constrain the index to some particular value or compute over the index to refine the choice 
of constructors. Hence, an inductive definition is a list of pattern choices, potentially 
ending with a computation over the indices. Since the case where no index computation 
is performed is merely a special case of the rule we give, we save space and do not write 
it down explicitly. 

The elaboration of pattern choices consists in interpreting the datatype patterns of 
each constructor choices. Then, the resulting labels are used to elaborate these con- 
structo rs choices. If there is a compu t ation over indices, we rely on elimination with a 



motive [Goguen et all 120061 . iMcBridd . 120021 ] to generate a type theoretic term from the 
elimination principle provided by the user. We then interpret each resulting sub-branch 
as a pattern choice itself. All in all, this elaboration step satisfies the following invariant: 

{r h I idatatel 
Patts , then V h code: (I) 
1 r (I) 9 patts ~^ code 



Note that we rely on the translation from datatype patterns to data telescope fFig. lllb]) : 
since we will be elaborating each individual constructor against these labels, we will gen- 
erate the valid equality constraints at the end of each telescope of arguments. 

Example 13 (Vector, constrained). The elaboration of datatype patterns simply pro- 
ceeds over the choices of constructors, triggering the elaboration of choices on nil and 
cons: 

Vec [A](n) D Vec A (n = 0) i> Vec [A](n = 0) 
^:SET,n:Nat h (Vec L4](n = 0)) 3 nilS[{'nil} ^ {'nil (->• '£ (n = 0) A_. T}] 

Vec [A] (n) D Vec^ (n = sue m) Vec [A] (n = sue m) 
A:SET,n:Nat h (Vec [A](n = sue to)) 3 cons (m : Nat)(a : A)(vs : Vec^ m) 

^[{'cons} ^ {'cons i-> 'S Nat Am. 'S A A_. 'var (*, m) 'x 'S (n = sue m) A_. T}] 

Patts 

^4:SET,n:Nat h Vec[>l](n) 3 [choices=] ~* [code=] 
where choices= and code= are the same as above. 

Example 14 (Vector, computed). Similarly for the alternative definition of vectors, this 
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triggers the elaboration of a motive, of the nil and cons patterns: 
Vec [A](n)D Vec^ n i> Vec [A](n) 



A: Set, n: Nat h Nat-case n 

~> Mho ih n . Nat-case n (An. (Vec [A](n))) ihO ih n 

€ (Vec [A](0)) ->-((m:Nat) ^(Vec L4](suc m))) ^(Vec [A](n)) 

Pnfta 

,4 : Set, n: Natl- Vec [A](0) 9 nil * -return {'nil} {'nil i— > '1} 
^4: Set, n: Nat, to: Nat h Vec [vl] (sue to) 9 cons (a : A)(vs : Vec a to) 

return {'cons} {'cons i-> '£ A A_. 'var (*, to) 'x '1} 
A : Set, n : Nat h Vec [A](n) 9 [choices^] P -w s [code_>] 

with choices-^, and code_> defined above. In turn, this triggers the elaboration of datatype 
choices for the nil and cons patterns: 

^4: Set, n : Nat h (Vec [^4](0)) 9 nil ^> [{'nil} i-4 {'nil i-» '!}] 
4:SET,n:Nath Vec [v4](0) 9 nil ^ return {'nil} {'nil ^ '1} 

A: Set, n: Nat, ?n:Nat h (Vec [^4](sucm)) 9 cons (a : ^4)(us : Vec^ to) 

^[{'cons} >-> {'cons i-» 'S 4 A_. 'var (*, to) 'x '!}] 

A: Set, n: Nat, to: Nat h Vec [A] (sue to) 9 cons (a : A)(us : Vec^ to) 



return {'cons} {'cons i-> '£ A A_. 'var (*, to) 'x '1} 



Elaboration of choices (Fig. HOcj ): The elaboration of the choice of datatypes is the 
same as for inductive types: we merely collect the tag and code of each individual 
constructor and return these as enumerations. This step is subject to the following 
soundness property: 

f T h I idatatel f r h E : Enuml/ 

Lemma 5. if < r\ , then < _. . ,_ ._ -,_ „.,, 

J (rh (Z) 9 choices £?[£h.T]' \V^T:EnumTts^lDesc\l\ D 

Example 15 (Vector, constrained). In the particular example of vector, there is only 
one choice of constructor when (n = 0) - namely nil - and when (n = sucm) - namely 
cons. Therefore, we obtain the elaboration of choices from the elaboration of the unique 
constructor, in both cases: 

A: Set, n: Nat h (Vec [A](n = 0)) 9 nil-%nil i-j- 'S (n = 0) A_. 1] 
^4: Set, n : Nat h (Vec [^4](n = 0)) 9 nil [{'nil} i— >■ {'nil '£ (n = 0) A_. '1}] 

j4:SET,n:Nat h (Vec [^4](n = sue to)) 9 cons (to : Nat)(a : ^)(w,s : Vec^ to) 
&['cons i-> '£ Nat Am. 'S 4 A_. 'var (*, to) 'x '£ (n = sue to) A_. '1] 
yl:SET,n:Nat h (Vec [A](n = sue to)) 9 cons (to : Nat)(a : A)(vs : Vec^ to) 

^[{'cons} i-> {'cons i-> '£ Nat Am. '£ 4 A_. 'var (*, to) 'x '£ (n = sue m) A_. T}] 
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Example 16 (Vector, computed). The same situation arises in the alternative definition 
of vector: once we have determined which index we are dealing with, there is a single 
constructor available. Hence, we move from the elaboration of choices to the elaboration 
of the unique constructor: 

A: Set, re: Nat h (Vec [A]{0)} 3 nil£['nil i-» 1] 
A:SET,n:Nat h (Vec[A}(0)) 3 nilS[{'nil} h-> {'nil ^ '1}] 

A : Set, re: Nat, m: Nat h (Vec [A](sucm)} 3 cons (a : A)(vs :\/ecA m) 

<£['cons H- 'E 4 A_. 'var (*, to) 'x '1] 
A: Set, n: Nat, ?re:Nat h (Vec [^4](sucm)} 9 cons (a : ^4)(vs : Vec^ m) 

S[{'cons} ^ {'cons ^ '£ ,4 A_. 'var (*, m) 'x '!}] 



Elaboration of constructor (Fig. HOdl ): Again, the elaboration of constructor is not 
any different from the inductive types case. It is subject to the following invariant: 

f T h / idatatel (Vht-.UId 
Lemma 6. If < n , then < ^ , , ir > h-,t> 

\r h (0 3 c£[t i — ^ code] \r h code : /Desc [Z] D 

Example 17 (Vector, constrained). Elaboration of the constructors is straightforward, 
simply switching to the elaboration of the arguments: 

A: Set, ra: Nat h (Vec [A] (n = 0)) 9e^'S(n = 0) A_.'l 
A: Set, re: Nat h (Vec [A] (n = 0)) 9 nil£['nil ^ '£ (n = 0) A_. '1] 



A:SET,re:Nat h (Vec [A] (ti = sucto)) 3 (to : Nat)(a : A)(vs : Vec^ m) 
4 '£ Nat Ato. '£ A A_. 'var (*, to) 'x '£ (n = sue to) A_. '1 
A:SET,?7,:Nat h (Vec [A] (n = sucm)) 9 cons (to : Nat) (a : A) (vs : Vec^ to) 
£['cons i-> '£ Nat Ato. 'E A A_. 'var (*, to) ! x '£ (n = sue to) A_. '1] 

Example 18 (Vector, computed). Similarly for the alternative definition, we have: 

A : Set, n : Nat h (Vec [A] (0)) 
A: Set, n: Nat h (Vec [A](0)) 3 nil£['nil t-> '1] 

A: Set, re: Nat, to: Nat h (Vec [A] (sue to)) 3 (a:A)(vs:VecA to) 4 'E A A_. 'var (*, to) 'x '1 
A : Set, re: Nat, rei: Nat h (Vec [A] (sue to)} 9 cons (a : A)(ws : Vec ,4 to) 

£['cons ^'Si A_. 'var (*, to) 'x '1] 
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Elaboration of arguments (Fig. Illa[ ): The elaboration of arguments follows the same 
principle as for inductive types. However, when elaborating a recursive argument, we 
must extract the indices for which that recursive step is taken. Besides, after having 
encoded the list of arguments, we must switch to translating the potential equality 
constraints, which are dictacted by the label type we are elaborating against. This step 
is subject to the following soundness property: 

{r h I idatatel 
A , then T h code: IDesc\l\o 
r h (/) 3 args ~^ code 

Example 19 (Vector, constrained). We then elaborate the arguments by unfolding the 
telescope, at which point we switch to elaborating the constraints. We do so immediatly 
in the nil case: 

Vec [A] (n = Q)j 'E (n = 0) A_. T 

A: Set, n : Nat h (Vec [A](n = 0)) 9e^>'E(n = 0) A_. T 

While a few steps are necessary to elaborate the arguments in the cons case, including 
the elaboration of the recursive call: 



Vec [A] (n = sue to) 'E (n = sue to) A_. T 
Vec [A] (n = sue to) 3 Vec^ m ^4 (*, m) 

,4 : Set, n: Nat, m: Nat h (Vec [A] (n = sucm)) 3 e 'T, (n = sue to) A_. '1 

A: Set, n: Nat, m: Nat h (Vec [A] (n = suc to)) 3 (vs : Vec^ to) ~-> 'var (*, m) 'x ! E (n = sue m) A_. '1 
A: Set, n: Nat, m: Nat h (Vec [A] (n = sue m)) 3 (a: A)(vs:\/ecA m) 

A 'E A A_. 'var (*, m) 'x 'E (n = sue m) A_. '1 
A: Set, n: Nat h (Vec [A] (n = suc m)) 9 (m : Nat)(a : J 4)(us : Vec^ m) 
4 'E Nat Am. 'E 4 A_. 'var (*, m) 'x 'E (n = sue m) A_. T 

Example 20 (Vector, computed). In the alternative definition, the process is similar: 

Vec [A](0)^A 

A: Set, n : Nat h (Vec [A](0)) 3 e-4'1 



Vec [A] (sue m) ~* '1 
Vec [A] (sue m) 3 Vec^ m ^4 (*, to) 
^4 : Set, n : Nat, m : Nat h (Vec [A] (sue m)) 3 e '1 

^4 : Set, n : Nat, m : Nat h (Vec [A] (sue to)) 3 (vs : Vec ,4 m) ~> 'var (*, m) 'x T 
A: Set, n: Nat, m: Nat h (Vec [A] (sue m)) 9 (a : A)(vs : Vec^ m)-w 'E A A_. 'var (*, to) 'x T 



25 



Elaboration of constraints (Fig. Illcj ): In order to generate the equality constraints, 
we simply traverse the label we are elaborating against. On constraints, we generate the 
corresponding equality constraint, using whatever propositional equality the system has 
to offer. On parameters and (unconstrained) indices, we simply go through. This step 
satisfies the following property: 

{r h I idatatel 
E q , then r h q : IDesc [/] o ■ 

I q 

Example 21 (Vector, constrained). We elaborate the constraints in the nil case - con- 
straining n to - and in the cons case - constraining n to sucm: 

Vec^'l Vec^T 



Vec [,4]^'! Vec[A]S'l 



Vec [A] (n = 0) S '£ (n = 0) A_. '1 Vec [A] (n = sue to) S >E (n = sue to) A_. '1 

Example 22 (Vector, computed). No equations are generated and, indeed, needed for 
the alternative definition of vectors: 

Vec^'l VecS'l 



Vec[4]S'l Vec[4]S'l 



Vec[i4](0)^?'l Vec [,4] (sue to) ^'1 

Extraction of indices (Fig. Illdl) : On the recursive calls, we must extract the indices 
at which the call is made. To do so, we match the type definition with the datatype 
label. Parameters are ignored while indices are paired together. On the datatype name, 
we inhabit 1. This ensures the following soundness property: 

{r h I idatatel 
L A , then r h is : [Z]d- 
I 3 T ~» is 

Example 23 (Vector, constrained). There is only one instance of recursive definition, 
in the cons case. Its elaboration goes as follow: 

Vec 3 Vec ^4 * 



Vec [A] 3 VecA * 



Vec [A] (n = sue to) 3 Vec^ m ^4 (*, to) 



Example 24 (Vector, computed). Similarly, the elaboration of the index for the recur- 
sive definition is as follow: 

Vec 3 Vec ^4 * 



Vec [A] 3 VecA ~4 * 



Vec [A] (sue to) 3 Vec^ m ^4 (*, m) 
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Having stated the soundness properties of each individual elaboration steps, we can 
now state and prove the soundness of the elaboration of inductive families: 

> > D 

Theorem 5 (Soundness of elaboration). IfT h data D[p : P](i Set where choices ~» A, 
then A h valid. 

Proof. First, we prove that labels elaborate to a type correct index (Lemma EJ. We 
then prove that the constraints generated by interpreting the label are valid descrip- 
tions (Lemma [8]). From these lemmas, we can prove the soundness of the elaboration 
of arguments by induction over the telescope of arguments (Lemma [7J. This gives 
straightforwardly the validity of the elaboration of a constructor (Lemma [6]). Using 
that Lemma over each constructors, we thus obtain the soundness of the elaboration of 
choices (Lemma [5]). Using this result and assuming the soundness of elimination with a 
motive, we prove Lemma [H This gives the desired result. 

□ 



5 Reflections on Inductives 

Having described our infrastructure to elaborate inductive definitions down to descrip- 
tions, we would like to give an overview of the possibilities offered by such a system. 
Indeed, in a purely syntactic presentation of inductives, we are stuck at the meta-level 
of the type theory: if we want to provide support to manipulate inductive types, it must 
be implemented as part of the theorem prover, out of the type theory. Alternatively, a 
quoting/unquoting mechanism could be provided but guaranteeing the safety of such an 
extension is likely to be tricky. 

Because our type theory reflects inductives in itself, the meta-theory of inductive types 
is no more than a universe. What used to be meta-theoretical constructions can now be 
implemented from within the type theory, benefiting from the various amenities offered 
by a dependently-typed programming language. In this Section, we present two exam- 
ples of such "reflection on induct ives". Our first example, reflecting constructions on 
constructors McBride et all 120041 ] . will appeal to the implementers: we hint at the pos- 
sibility of implementing key features of the type theory within itself, a baby step toward 
bootstrapping. Our second example, providing a user defined deriving mechanism, 
should appeal to programmers: we illustrate how programmers could provide generic 
operations over datatypes and see them automatically integrated in their development. 
For simplicity and conciseness, we shall define these mechanisms over our universe of 
inductive types, Desc. Nonetheless, it is straightforward, but more verbose, to extend 
these constructions to inductive families. 

5.1 A few constructions on constructors, internalized 



McBride et al.l [20041 ] describe a collection of lemmas that theorem prover's implementer 
would like to export with every inductive type. In that paper, the authors first show how 
one can reduce case analysis and course-of-value recursion to standard induction. Then, 
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they describe two lemmas over datatype constructors: no confusion - constructors are 
injective and disjoint - and acyclicity - we can automatically disprove equalities of the 
form x = t where x appears constructor-guarded in t. 

However, since this paper works on the syntactic form of datatype definitions, it is 
rife with ". . . " definitions. For instance, the authors reduce case analysis to induction 
with no less than ten ellipsis in the construction. In our system, we generically derive 
case analysis by a mere definition within the type theory: 

case(Z> : Desc) (P:fj,D^ Set) (cases :((d: \DJ {^D)) — ► P(\nd)))(x : fiD) : Px 
case D P cases x i— > induction D P (Ac/. A_. cases d) x 

Similarly, the authors specify and prove the no confusion lemma over the skeleton of 
an inductive definition. In our system, this result is internalized through two definitions. 
In the following, we will assume that D is a tagged description, i.e. D = 'tr E T where 
E is the finite sets of constructor labels. An inhabitant of \i D is therefore a pair in (c, a) 
with c representing the constructor name and a the tuple of arguments. We state the 
NoConfusion lemma over such code: 

NoConfusion (x:fiD) (y.fiD) : Seti 

NoConfusion (in (x, a x )) (in (y, a y )) | decideEq-EnumT x y 

NoConfusion (in (x, a x )) (in (x, a y )) | equal refl i— s> (P : Set) — >(a x = a y — > P) —¥ P 

NoConfusion (in (x, a x )) (in (y, a y )) \ not-equal q i— >■ (P:Set)— >P 

and then prove it by deciding the equality of enumeration index to discriminate con- 
structor names: 

noConfusion (x:^lD) (y.fiD) (q:x = y) : NoConfusion x y 

noConfusion (in (x, a x )) (in (y, a y )) q \ decideEq-EnumT x y 

noConfusion (in (x, a x )) (in (x, a y )) q equal refl H> AP. Arec. rec q 

noConfusion (in (x, a x )) (in (y, a y )) q not-equal neq i— > AP. 0-elim (neq q) 

At this stage, we have proved this lemma generically, for all tagged descriptions. Hence, 
after having defined a new datatype, a user can directly use this lemma on her definition. 
For convenience, a subsequent elaboration phase could also specialize such lemma to the 
particular definition. 

5.2 Deriving operations on datatypes 

Another possible extension of our system is a generic deriving mechanism. In the 
Haskell language, we can write a definition such as 

data Nat: Set where 
Nat 9 

| sue (n: Nat) 
deriving Eq 

that automatically generates an equality test for the given datatype. Again, since 
datatypes are a meta-theoretical entity, this deriving mechanism has to be provided 
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by the implementer and, template programming aside, they cannot be implemented by 
the programmers themselves. 

In our framework, we could extend the elaborator for datatypes with a deriving 
mechanism. However, for such a mechanism to work, we must restrict ourselves to 
decidable properties: for example, if the user asks to derive equality on a datatype 
that do not have a decidable equality (e.g. , Brouwer ordinals), the system should fail 
immediately. To solve this issue, we add one level of indirection: while we cannot decide 
equality for any datatype, we can decide whether the datatype belongs to a sub-universe 
for which equality is decidable. Hence, to introduce a derivable property P in the type 
theory, the programmer would populate the following record structure: 



For example, in the case of equality, the programmer has first to provide a function 
eqDesc: Desc — > Seti. One possible (perhaps simplistic, but valid) sub-universe consists 
only of products, finite sums, recursive call, and unit: it is enough to describe natu- 
ral numbers and variants thereof. She then implements a procedure membershipEq : 
(D : Desc) —> Decidable (eqDesc D) deciding whether a given Desc code fits into this sub- 
universe or not. Recall that Decidable A corresponds to A + —>A. It should be clear 
that the membership of a Desc code to our sub-universe of finite products and sums 
is decidable. Finally, she implements the key operation deriveEq : eqDesc D — )■ (x y : 
fiD) Decidable (x = y) that decides equality of two objects, assuming that they belong 
to the sub-universe. This implements the structure Eq : Derivable (AD. (x y.[iD)—> Decidable 

While elaborating a datatype, it is then straightforward - and automatic - for us to 
generate its derivable property, or reject it immediately: we simply compute membership 
on the specific code. If we obtain a negative response, we report an error. If we obtain 
a positive witness, we pass that witness to derive and instantiate the derived property. 

For example, since natural numbers fit into the eqDesc universe, the elaboration ma- 
chinery would automatically generate the following decision procedure 



without any input from the user but the deriving Eq clause. Here, witness is a library 
function that extracts the witness from a true decidable property: applied to NatD, the 
function membershipEq computes a positive witness that we can simply extract. 




Nat-eq (x y : Nat) : Decidable x = y 

Nat-eq x y i-> deriveEq (witness (membershipEq NatD) *) 
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6 Conclusion 



In this paper, we have striven to give a coherent framework for elaboration in type 
theory. We have organized our system around two structuring ideas. First, by using the 
flow of typing information, we obtain a richer and more flexible term language. Second, 
by using types as presentation of high-level concepts, such as inductive definition, we 
can effectively guide the elaboration process. This technique is conceptually simple and 
therefore amenable to formal reasoning. This simplicity together with the soundness 
proofs should convince the reader of its validity. 

From there, we believe that reasoning on inductive definitions can be liberated from 
the elusive ellipsis: proofs and constructions on in ductives ought to happen within the 
type theory itself. After lHarper and Stond 2000 ]. we claim that if the treatment of 
datatypes is conceptually straightforward then it ought to be technically straightfor- 
ward and implemented as a generic program in the type theory. For non-straightforward 
properties, our results should be reusable across calculi - such as the Calculus of Induc- 
tive Constructions - and not too rigidly tied to our universe of datatypes. Besides, we 
were careful to present elaboration as a relation rather than a mere program, making it 
more amenable to abstract reasoning. 

To support our claim that inductives should be bootstrapped, we have presented 
two possible extensions to the elaboration process. While we did not formalize these 
examples, our expectations seem reasonable and our experience modeling them in Agda 
further supports this impression. We have seen how generic theorems on inductive types 
can be internalized as generic programs: besides the benefit of reducing the trusted 
computing base, their validity is guaranteed by type checking. Also, we have glimpsed 
at a generic deriving mechanism: with no extension to the type theory, we are able to 
let the user define sub-universes that support certain operations. These operations could 
then be automatically specialized to the datatypes that support them, all that without 
any user intervention. 



Future work: A next step would be to adapt our syntax to coinductive types. Similarly, 
it would be interesting to see if it scales to inductive-recursive definitions. On the 
implementation side, we are currently implementing these various systems in a toy type 
theory. This step will require a formalization of our deriving mechanism. Also, we will 
have to generate the specialized induction principles (such analysis and course- 

of-value recursion) as well as the constructions on constructors. Finally, an interesting 
challenge would be to internalize the elaboration process itself in type theory, hence 
obtaining a correct-by-construction translation. 
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